Towards #1740

Changes

• Current implementation of Metrics SDK uses a RwLock<Hashmap> for aggregating measurements. RwLock brings in significant amount of contention even for concurrent reads
• This PR showcases how we could use flurry crate's concurrent Hashmap instead of a RwLock<Hashmap>.

The performance gains are huge!

Stress Tests results:

Machine details:

OS: Ubuntu 22.04.4 LTS (5.15.153.1-microsoft-standard-WSL2)
Hardware: Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz, 16vCPUs,
RAM: 64.0 GB

• Counter throughput went up from 9M to 45M iterations per sec
• Histogram throughput went up from 7.5 M to 35M iterations per sec

Benchmarks

• The benchmark results are comparable. There is no significant difference in the benchmark results.

Note for reviewers

This PR is not meant for merging as-is. It's meant to show that we can utilize a more efficient concurrent data structure to our advantage. If we indeed decide to use flurry's Hashmap, we have to address the following:

1. There is a potential race condition during collect for Delta temporality. This needs to be fixed to avoid losing measurements.
2. Provide meaningful Ord implementations for KeyValue. Ord implementation for the Hashmap's key type is a requirement from flurry. For this PR, I have added a very basic implementation just to unblock myself from testing the Hashmap.
3. We need to offer this under a feature flag. We don't want to add dependency on an external crate by default.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)